techfandomcom-20200213-history
TechWiki:Consensus
This is a Teklogs policy, When editing this page, please ensure that your revision reflects consensus. When in doubt, discuss first on the talk page. This policy has been copied from Wikipedia and needs to be adopted to Teklogs. ---- Teklogs works by building consensus. Consensus is an inherent part of the wiki process. Consensus is typically reached as a natural product of the editing process; generally someone makes a change or addition to a page, and then everyone who reads the page has an opportunity to either leave the page as it is or change it. In essence, silence implies consent if there is adequate exposure to the community. In the case of policy pages a higher standard of participation and consensus is expected. Whether the change or addition to the page is reverted, or modified or not, any refinements or objections can be discussed on the discussion page. When there are disagreements, they are resolved through polite reasoning and cooperation. Negotiation on takes place in an attempt to develop and maintain a neutral point of view. If we find that a particular consensus happens often we write it down as a guideline, to save people the time having to discuss the same principles over and over. In the rare situations where consensus is hard to find, the dispute resolution processes provide several other ways agreed by the community, to involve independent editors and more experienced help in the discussion, and to address the problems which prevent a consensus from arising. When consensus is referred to in Teklogs discussion, it always means 'within the framework of established policy and practice'. Even a majority of a limited group of editors will almost never outweigh community consensus on a wider scale, as documented within policies. Reasonable consensus-building Consensus develops from agreement of the parties involved. This can be reached through discussion, action, or more often, a combination of the two. Consensus can only work among reasonable editors who make a good faith effort to work together to accurately and appropriately describe the different views on the subject (e.g. insisting on insertion of an insignificant factoid into an article in opposition to many other editors has been judged a violation of consensus; see Wikipedia:Requests for arbitration/Charles Darwin-Lincoln dispute). It is difficult to specify exactly what constitutes a reasonable or rational position. Good editors acknowledge that positions opposed to their own may be reasonable. However, stubborn insistence on an eccentric position, with refusal to consider other viewpoints in good faith, is not justified under Teklogs' consensus practice. (Note that in the rare case that the "eccentric" position turns out to have merit, the consensus can change.) Even if an editor's contributions appear to be biased, keep in mind that their edits may have been made in good faith, out of a genuine desire to improve the article. Editors must, in almost all situations, assume good faith and must always remain civil. The assumption of good faith is, of course, a mutual obligation between editors. Consensus can change Consensus is not immutable. It is reasonable, and sometimes necessary, for the community to change its mind. Past decisions, are open to challenge and should not be "binding" in the sense that the decision cannot be taken back. Teklogs's processes remain flexible for several reasons including: *new people bring fresh ideas, *as we grow we evolve new needs, and *sometimes we find a better way to do things. Sometimes a representative group makes a decision on behalf of the community as a whole, at a point in time. More often, people document (changes to) existing procedures at some arbitrary point in time after the fact. However, if one person or a limited group of people can reasonably demonstrate a change in consensus, then it is reasonable to effect the change at a process page. Boldness is encouraged, but good judgment should be used. Remember that we try to document actual practice, not prescribe rule-sets. "Asking the other parent" It is very easy to create the appearance of a changing consensus simply by asking again and hoping that a different and more sympathetic group of people will discuss the issue. This, however, is a poor example of changing consensus, and is antithetical to the way that Teklogs works. Teklogs' decisions are not based on the number of people who showed up and voted a particular way on a particular day; they are based on a system of good reasons. Attempts to change consensus must be based on a clear engagement with the reasons behind the current consensus — so in the new discussion section, provide a summary and links to any previous discussions about the issue on the articles talk page, or talk page archives, to help editors new to the issue read the reasons behind the consensus so that they can make an informed decision about changing the consensus. A good sign that you have not demonstrated a change in consensus, so much as a change in the people showing up, is if few or none of the people involved in the previous discussion show up for the new one. In this situation you may find that any changes you make to the article are quickly reverted by people outside the new talk page discussion. Do not be tempted to edit war but instead post comments on the talk page encouraging others to participate in the new discussion. Asking for a consensus in a completely different "venue" or section of Wikipedia, in the hope of finding more support for a failed proposal, is known disapprovingly as forum-shopping. It's better to find the most appropriate page for discussing the topic, then ask there first and only. (This doesn't mean you can't take your proposal elsewhere if you're told you chose the wrong page for the topic.) Consensus in practice Consensus does not mean that everyone agrees with the outcome; instead, it means that everyone agrees to abide by the outcome. The following description of consensus, from the Wikipedia mailing list, argues a difference between consensus and unanimity: In fact WP's standard way of operating is a rather good illustration of what it does mean: a mixture across the community of those who are largely agreed, some who disagree but 'agree to disagree' without disaffection, those who don't agree but give low priority to the given issue, those who disagree strongly but concede that there is a community view and respect it on that level, some vocal and unreconciled folk, some who operate 'outside the law'. You find out whether you have consensus, if not unanimity, when you try to build on it. In practice, a lot of people look in on an issue and check to see if a (mere) majority exists in favor of their position. While this quick and dirty rule helps you to figure out what to spend your time on, it is obviously *not* the same thing as finding the actual consensus (or what it will end up as). To do that, you actually need to carefully consider the strength and quality of the arguments themselves (including any additional concerns that may have been raised along the way), the basis of objection of those who disagree, and in more complex situations, existing documentation in the project namespace should also be checked. If you are volunteering to carry out an action on the basis of rough consensus, only this thorough approach is acceptable. Minority opinions typically reflect genuine concerns, and discussion should continue in an effort to try to negotiate the most favorable compromise that is still practical. In situations with a deadline, a perfect compromise may not have been reached by all participants at the deadline. Nevertheless, a course of action should be chosen that is likely to satisfy the most persons (rather than merely the majority). Running roughshod over the (then) minority is the best way to get yourself into almost unlimited amounts of trouble. Besides, next time someone from that minority might be the final closer, and you might be one of the people in a minority, so it's a good idea to be a gentleperson at all times and set a good example. New users who are not yet familiar with consensus should realize that a poll (if one is even held) is often more likely to be the start of a discussion than it is to be the end of one! The final course of action is usually decided upon during discussion. This is another reason you should always provide a further rationale during a poll. People can then engage you in discussion and work out an acceptable compromise. This can be very empowering. Provided you do your homework right, at times your opinion alone will be enough to tip the scales, or even decide the issue all on its own! Note on use of discussion page While the consensus process does not require posting to the discussion page, it can be useful and is encouraged. It is also a good idea to check the discussion page before making an edit, because someone may have thought of it before, or discussed something that sheds more light on the subject. Otherwise "be bold"; ultimately, improving articles is what Wikipedia is all about. Edit summaries are short and can be misinterpreted. Discussing your edit may help it attract consensus. Sometimes misunderstandings occur because people see the edit before any rationale is posted on the talk page. Posting a comment before editing is the best way to avoid such misunderstandings (but if you post a comment before editing, please make the associated edit immediately afterwards). To avoid falling into a similar trap yourself: if you are unsure about an edit someone has made, wait a reasonable amount of time to allow them to post a comment. Exceptions There are a few exceptions that supersede consensus decisions on a page. *Declarations from Jimmy Wales, the Board, or the Developers, particularly for server load or legal issues (copyright, privacy rights, and libel) have policy status (see Wikipedia:Policies and guidelines#Sources of Wikipedia policy). *Office Actions on a specific article (such as stubbing or protecting it) are outside the policies of the English Wikipedia. *Consensus decisions in specific cases are not expected to override consensus on a wider scale very quickly - for instance, a local debate on a WikiProject does not override the larger consensus behind a policy or guideline. The project cannot decide that for "their" articles, said policy does not apply. *Foundation Issues lay out the basic principles for all Wikimedia projects. These represent the largest consensus decisions achievable among all Wikimedia projects. These consensuses are fundamental and affect all other Wikimedia and Wikipedia agreements. This means they evolve very slowly. See also ;Wikipedia articles * wikipedia:Consensus * wikipedia:Consensus decision-making * wikipedia:Groupthink ;Wikipedia project pages * wikipedia:Wikipedia:Featured article candidates * wikipedia:Wikipedia:BOLD, revert, discuss cycle ;Essays * wikipedia:Wikipedia:The role of policies in collaborative anarchy * wikipedia:Wikipedia:Silence and consensus * meatball:AgreeToDisagree * meatball:HealthyConflict